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METHOD AND SYSTEM FOR IiZNKING 
CERTXFXCATES TO SIGNED FIIiES 

Copyright: not:xce 

A portion of the disclosure of this patent document 
5 contains material which is sxibject to copyright protection. 
The copyright owner has no objection to the facsimile repro- 
duction by anyone of the patent disclosure, as it appears in 
the National Patent and Trademark Office patent file or 
records, but otherwise reserves all copyright rights 
10 whatsoever. 

Field of the Xnventxon 

The present invention relates generally to network 
computing secixrity and more specifically to a method amd 
systems for linking a digital certificate to a digitally 
15 signed file that can be accessed through a network so as to 
provide information relative to the signer identity and the 
validity of the signature that can be used before opening 
the file. 

Background o£ t;he Xnvent;lon 

20 To inqprove data tramsmission security over computer 

networks and to prevent digital forgery, a digital signature 
is commonly used to authenticate a file i.e., to check file 
integrity and to authenticate signer. Such digital signature 
allows, for example, to control the source of a received 

25 file, and to verify the file integrity. A digital signature 
asserts that the user corresponding to the digital signature 
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wrote or otherwise agreed with the contents of an electronic 
dociament or other information object to which the digital 
signature is appended- As with written signatures, digital 
signatures provide authentication of the signer's identity, 
5 acceptance of the terms stated in the signed docximent, proof 
of the intecprity of the document's contents, and non 
repudiation (in other words, the signer cannot deny what 
he/she has signed) . Digital signatures are generally based 
upon public key algorithms wherein security is provided 
10 through keys independently of the used algorithm, which may 
be freely published or analyzed, 

A digital certificate can be considered as an attach- 
ment to a signed document, to link the identity of the 
signer of the document to his/her public key, A digital 

15 certificate provides a cryptographic ptiblic key that allows 
another party to encrypt information for the certificate's 
owner. A digital certificate also allows to verify that a 
user sending a document is who he/she claims to be, and to 
provide the receiver with the means to encode a reply. A 

20 certificate therefore securely identifies the owner of the 
public key pair, which is used to provide authentication, 
authorization, encryption, and non- repudiation services . A 
digital certificate contains the signer's public key and 
bears the digital signature of a Certification Authority 

25 (CA) . The most widely used standard for digital certificates 
is X,509, Version 3, "The Directory-Authentication Framework 
1988", promulgated by the International Telecommunications 
Union (ITU) , which defines the following structure for 
public-key certificates: 

30 - version field (identifying the certificate format) 

- Serial Number (unique within the CA) 
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- Signature Algorithm (identifying the issuer's hash and 
digital signature algorithms used to sign the certificate) 

- Issuer Name (the name of the CA) 

- Period of Validity (a pair of "Not Before", and "Not 
5 After" Dates) 

- Subject Name (the name of the user to whom the certifi- 
cate is issued) 

- Subject's Public Key field (including Algorithm name and 
the Public Key of the siibject) 

10 - Extensions 

- Signature of CA 

A certification authority is the third party that 
everyone trusts whose responsibility is to issue digital 
certificates providing the link between the signer and the 

15 signer's public key* A certification authority (CA) also 
keeps records about the transactions that occxir using 
certificates it has issued. An individual wishing to sign a 
document applies for a digital certificate from a Certifica- 
tion Authority. The digital certificate is digitally signed 

20 by the issuing Certification Authority that ensures both 
content and source integrity. The CA makes its own public 
key readily available through, for example, print publicity 
or on the Internet. The act of digitally signing makes the 
certificates substantially tamperproof, and therefore 

25 further protection is not needed. The strength of protection 
ecjuates directly to the strength of the algorithm and key 
size used in creating the issuer's digital signature (hash 
and digital signature algorithms) . 

The signature verification process checks the digital 
30 signature appended or attached to a docioment using the 
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pxiblic verification key extracted from the digital certifi- 
cate, issued by the CA, that must be also appended to or 
referenced in the document. Using the public key of the 
signer, the signature verification process recovers from the 
digital signature, the hash value, computed by the signer, 
in the file that was signed using the private key of the 
signer during the authentication process. To verify that the 
file is authentic, the receiver confutes also the hash value 
of the document, and then compares the deciphered hash value 
with the real hash value, computed from the file. If both 
hash values are identical, the file is accepted as 
authentic, otherwise, the file is rejected as being 
corrupted or fake. 

Once the digital signature of a file has been computed 
and the file has been signed with the digital signature for 
verification purposes, a digital certificate must be associ- 
ated with the signed file to make possible the verification 
of the digital signature by the recipient. 

Generally, a digital certificate used for authenticat- 
ing a file is transmitted as a separate file, appended to 
the file it authenticates e.g., as part of a file wrapper 
structure, or alternatively, the certificate can be 
retrieved from a reference or address e.g., the URL of the 
certificate on the issuing CA Web Se3rver. 

Transmitting and maintaining digital certificates and 
signed documents as se p arate files e.g., the digital 
certificate associated to a signed document is stored in the 
user's workstation or in a server, presents the advantage of 
supporting file authentication at any time in a simple and 
well landers tood way. However, if documents are later passed 
on or moved to new recipients, associated digital 
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certificates can be lost, accidentally removed ^ or even 
intentionally removed on the way in an attempt to cheat. 

Wrapping a file with delimiters emd appending the 
digital certificate, or the URL of said certificate on the 
5 issuing CA Web Server, at the end of the signed file is 
convenient, since both the certificate, or the certificate 
address, and the signed content travel together. Conversely, 
the wrapper and the certificate, or the certificate address, 
will typically need to be removed before the file can be 

10 used. Thus, signature validation only occurs when the 
document is retrieved. If the docxament is later passed on or 
moved, it may be difficult to check again, since the 
certificate, or the certificate address, could be lost. 
Furthermore, the method is not compatible with standard file 

15 formats such as image, video, audio or executable files that 
cannot be recognized prior to authentication. 

When a recipient receives an electronic document, if 
the digital certificate has been appended to the signed 
document, the recipient must perform the following tasks: 

20 - open the electronic document; 

- identify and extract, from the electronic docxoment, the 
digital certificate and the digital signature portions 
appended to this electronic document; 

- identify the address and contact the CA to check that 
25 the appended certificate is a valid certificate, using the 

digital certificate content; and, 

- verify the signature using the p\xblic key in the 
certificate- 
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It must be observed that if the digital certificate is 
appended to the received electronic document, the recipient 
must open the document file for accessing the digital 
certificate rectuired to verify the signature. Even when the 
5 certificate, instead of being appended, would be referenced 
e.g., as a network address or URL, in the received document, 
the address from which the certificate e.g., from a CA Web 
Server or directory archive, can be accessed or retrieved, 
must also be appended by the sender to the signed document, 
lb Therefore, it is also required to open the received dociament 
to get said address needed for accessing the digital 
certificate . 

Thus, there are security problems related to the 
methods described above for verifying the authenticity of 
15 received or accessed files by the recipient: 

- when certificates are sent as separate files, the 
associated digital certificates could be lost if the 
signed files are later passed on or moved to new recipi- 
ents.- In such case, it is impossible to verify these 
20 signed files. 

when certificates, or certificates addresses, are 
appended to the signed files, recipients must open and 
process the received files to verify said files. Before 
opening a received, files, parsing the content for 

25 locating, cind retrieving, or accessing, the associated 

certificate, there is no way to determine in advance, 
whether the received file has been signed or not i.e., 
whether it is an "authenticated" file or an " inqpersonated" 
file (a non-signed file) . Likewise, it is impossible to 

30 determine whether or not the certificate is valid i.e., if 

it has been issued by a CA, if it has not been revoked, 
and if the certificate date is valid. 
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It ±s also to be noticed that opening files for verifi- 
cation represents an important secxxrity concern. 

Many viruses spread on the Internet on e-mail attach- 
ments distributed as "impersonated". If a received imperson- 
ated file has been maliciously infected by a virus, opening 
the infected file for the simple purpose of signature 
verification almost surely may "open" the door for infecting 
the receiver's computer » This is a "security hole" common to 
all signature methods described above, as illustrated by 
operation of the class of piiblic-key algorithms discussed 
herein before. 

Certificates must be issued by certificate authorities. 
If a certificate becomes compromised, the certificate 
authority can later revoke the certificate, thus rendering 
invalid all files signed after the signature's revocation 
date. A certificate could become compromised if an \inauthor- 
ized third-party obtained the private key associated with 
the certificate. This private key is typically stored on the 
signer's computer. With the private key, an unauthorized 
person could essentially forge a signattire. If the recipient 
receives a file signed with a revoked certificate, it is 
must be discarded as invalid or fake. 

Therefore, before opening a received file, it would be 
advisable to check: 

~ if the file has been signed i.e., if it contains a 
digital signature and a digital certificate appended or 
referenced; 

~ the issuer name i.e., the name of the CA; 

- the name of the user to whom the certificate has been 
issued; and. 
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- the validity period of the certificate. 

Therefore, there is a need to provide a method and 
systems for accessing a digital certificate from a signed 
file before opening said file, so as to enable the recipient 
5 of the file to determine if the received file has been 
signed i.e., authenticated, and to check the identify of 
signer e.g. , contacting the signer by e-mail, and the valid- 
ity of the digital certificate before opening said file for 
signature verification, 

10 Summary of t:he Xnvention 

Thus, it is a broad object of the invention to remedy 
the shortcomings of the prior art as described here above. 

It is another object of the invention to provide a 
method and systems adapted for enabling a recipient to check 
15 whether or not a received file is a signed file, before 
opening said file. 

It is a further object of the invention to provide a 
method cmd systems adapted to access the digital certificate 
of a signer, before opening the corresponding files. 

20 It is still a further object of the invention to 

provide a method and systems adapted for providing the 
identity and address of the signer of a file to the recipi- 
ent of this file so as to verify signer identity, before 
opening a suspicious file. 

25 The accomplishment of these and other related objects 

is achieved by a method for encoding in the filename of a 
signed file., an address from which the certificate required 
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to authenticate said signed file can be accessed, said 
method comprising the steps of, 

encoding said address from which the certificate 
required to authenticate said signed file can be accessed; 

5 - merging said filename and said encoded address in a new 

filename; and, 

- renaming said signed file with said new filename, 

wherein said filename and said encoded addresses are 
separated by a control character, 

10 and by a method for authenticating a signed file having 

a filename wherein an address from which the certificate 
required to authenticate this signed file can be accessed is 
encoded, said method comprising the steps of, 

- extracting said encoded address; 
15 - decoding said encoded address; 

- accessing said certificate required to authenticate said 
signed file using said decoded address, 

- authenticating said signed file using said accessed 
certificate- 
so Further advantages of the present invention will become 

apparent to the ones skilled in the art upon examination of 
the drawings and detailed description. It is intended that 
any additional advantages be incorporated herein. 

B3rxe£ Descrip^iozi of the Drawings 

Figure 1 , comprising figures la, lb, euad Ic, illustrates 
an example of the algorithm used for encoding. 
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in the filename of a file, the address or URIj 
wherein the certificate used to signed this file 
is stored. 

, comprising figures 2a and 210, illustrates an 
example of the algorithm that is used to sign an 
electronic document and of the algorithm that is 
used to check the integrity and to verify the 
signature of a signed file, respectively, 
depicts an example of the environment wherein 
the invention can be implemented, 

shows em. example of a signed file content 
wherein the filename is encoded according to the 
invention- 

, comprising figures 5a to 5f, illustrates an 
example of the user's interface when using the 
invention. 

Detailed Description of the Preferred Embodiment 

According to the invention, the filename of a file that 
is accessed locally or through a computer network is used to 
5 encode the address, or URL, from which the certificate that 
can be used to check the integrity and to verify the signa- 
ture of the file can be accessed. A lexicography is deter- 
mined so as • to avoid particular characters that may be 
forbidden by the fil^ syst^a, e.g., "X" with Microsoft 

10 Windows system (Windowts xs a T^>-;=idiemark of Microsoft Corpora- 
tion) , and/ or to encode the addresses so as to reduce their 
sizes. Addresses to be encoded may be of any forms e.g., 
local addresses, addresses in private networks or Internet 
addresses, however, for sake of illustration, the examples 

15 given in the following description are based on URL type of 
addresses. The address from which the certificate can be 
accessed can be encoded either when the file is transmitted 



Figure 2 

Figure 3 
Figure 4 

Figure 5 
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from a server to the user system or when it is locally saved 
or transmitted to smother system. 

Figure 1 illustrates an example of the algorithm used 
to encode a certificate address. As shown on figure la^ a 
5 first step consists in getting the primary filename of the 
file (box 100), i.e. the filename of the file, and the 
address or URL of the certificate that is recpiired to check 
the integrity and to verify the signature of the file, 
referred to as certificate address in the following descrip- 
10 tion (box 105) . Then, the certificate address is encoded 
(box 110) cind merged with the primary filename of the file, 
using particular separators (box 115) before the file is 
renamed with the filename comprising the primary filename 
and the encoded certificate address (box 120) . 

15 Figure lb depicts an example of the encoding algorithm 

(box 110) . A variable i is set to zero (box 125) and the 
character is extracted from the certificate address string 
(box 130) • A test is performed to determine whether the 
extracted character is valid or otherwise forbidden by 

20 filename syntax rules imposed by the file system of the 
user's device (box 135) • If the extracted character is a 
filename valid character, variable i is incremented (box 
150) and a test is performed to determine if variable i has 
reached its maximiim value that is, if all characters of the 

25 certificate address string have been processed (box 155) - If 
variable i has not reached its itiaximiim value, the last four 
steps of the algorithm are repeated (boxes 130 to 155) . 
Else, if variable i has reached its maximum value, the 
process is stopped. If the character extracted from the 

30 certificate address string is forbidden by the filename 
syntcLx rules, a corresponding valid character, or group of 
characters, is selected in lexicography table 145 and this 
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selected character, or group of characters, replaces the 
forbidden one (box 140) . Then variable i is incremented and 
the same test described before is performed to determine if 
variable i has reached its maximiim value. 

5 As an illustration of the algorithm described above, 

consider the case of a file based on Microsoft Word format 
(Word is a Trademark of Microsoft Corporation) named 
"Berry.doc", that a user would like to send to someone else 
as an e-mail attachment, using to this purpose a lexicogra- 
10 phy table to encode the certificate address string into the 
filename, wherein 

" : " is associated to " • • " 

" / " is associated to " ( " 

To check the integrity and to verify the signature of 
15 this document file, it is required to use the certificate 
corresponding to the private key that has been used to sign 
this file. For sake of illustration one can considered that 
this certificate can be downloaded from the following URL: 

ht tp : / /www . cer tauth . com/ cer ti f icates /Lewis Carroll . cer 

20 When the originator of the dociament "Berry.doc" signs 

the document, an option such as "Copy path to file" can be 
selected to encode the URL of the certificate repository 
wherein the certificate required to check the integrity or 
to verify the signature of the document can be accessed. 

25 The filename is modified according to the algorithm 

illustrated on figure 1. Firstly, by using the previous 
lexicography table, the certificate repository URIi is 
encoded as follows : 

http. . ( (vAJiJ.cert:aut:h.com(certi-£icates (Let/is Carroll. cer 



FR920040018 



L3 

Then, the encoded URL is merged with the filename • In 
this example, the encoded URL is enclosed in parenthesis 
that are used as separators. The encoded URL is inserted in 
front of the extension dot of the primairy filename as 
5 follows : 

Berry (http. . < (www.certautli.com(cert:ificates (Lewis Carroll-cer) .doc 

and the file is renamed using this modified filename • 

It must be noticed that, for sake of illustration^ this 
encoding algorithm is purposely very simple. A preferred one 
10 would consist in replacing a sequence of forbidden charac- 
ters by a single one e.g., replacing "//:" by "(". Likewise, 
some sets of characters may be replaced by more compact 
codes e.g., replacing "http://" by "H!". 

Figure Ic depicts an e-mail 160 wherein the filename 
15 165 of the attached file 17 0 has been modified to embed the 
URL of the certificate address according to the previous 
algorithm. 

When the attachment of the above mentioned e-mail is 
selected to be processed by the receiver, a test is 
20 performed to determine whether or not the user requests an 
integrity check or a signature verification so as to deter- 
mine whether or not the certificate address must be 
extracted from the filename and decoded. 

Using the same table of lexicographic transformations 
25 as the one that has been used by the sender of the file to 
encode the certificate address, the certificate address or 
URL is extracted and decoded from the filename. To that end, 
certain symbols or groups of symbols of the ^encoded URL" 
are replaced by symbols or characters that are compatible 
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with URL conventions on Internet, as mentioned above, to get 
the decoded emd valid URL. Using the same exainple as before, 
the decoded certificate address is, 

http: //viww.cex:tauth.com/certi£lcates/I«ewxs Carroll. cer 

5 Certificates are stored in a database of a certifica- 

tion authority server and, possibly, locally in the certifi- 
cate's ovmer device. Each certificate comprises at least a 
public key that can be accessed by third parties to check 
the validity or to verify the signature of a signed file. 

10 The pxablic key of a certificate corresponds to a private key 
that is known only by the certificate's owner and by the 
certification authority, this private key being used to sign 
files. In a preferred embodiment, the certificates also 
comprise additional information such as the owner's name, 

15 the certificate's validity period and the signature 
algorithm as mentioned above. It must be clear that a 
private key is only known by the certificate's owner and by 
the certification authority while all the other information 
relative to the private key and organized as a certificate 

20 is public and can be accessed by any third party knowing the 
certificate address or URL. 

Figure 2, coitiprising figures 2a and 2b, illustrates an 
example of the algorithm that is used to sign an electronic 
• dociament and of the algorithm that is used to check the 
25 integrity and/or to verify the signature of a signed file, 
respectively . 

If the sender has not already a certificate issued by 
certification authority, he/she must apply for the certifi- 
cation authority to issue it.. This must be made one time for 
30 a validity period since a certificate has a validity period. 
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Thus, the private key associated to a ceirtificate issued by 
the certification authority can be used by the sender to 
sign all docximents during the certificate validity period. 
To get a certificate the sender sends a request to the 
5 certification authority (step 200) with required information 
such as sender's name- After having assigned a pair of 
private and public keys, the certification authority creates 
a certificate and transmits the private key as well as the 
certificate address to the user having sent the request, 
10 using a secure connection. The private key and the certifi- 
cate address are pref eraJDly stored locally on the user ' s 
device however, this information can be stored on a secxire 
server of the certification authority or on personal data 
storage means, such as a smart card. 

15 After having selected the file to sign coid once having 

received or recovered the required private key and the 
associated certificate address (step 210) , the user signs 
the file (step 215) . To that purpose, a standard certifica- 
tion algorithm is used to compute a signature based on the 

20 file to be signed and the private key e.g. Message-Digest- 5 
(MD5) with RSA or SHA hashing algorithm with RSA. 

In a preferred embodiment, the signature is appended to 
the document as illustrated on figure 4 wherein the signa- 
ture (410) is located at the beginning of the file (400) and 

25 separated from the content of the dociament (405) by tags 
"BEGIN SIGasJATURE" and "END SIGNATURE". Then, the address or 
URIi of the server wherein the public key that is required to 
check the integrity or to verify the signature of the file 
is encoded in the filename (step 220) as described by refer- 

30 ence to figure 1» As mentioned above, the address or URL 
wherein this piiblic key is stored is prefereibly provided by 
the certification authority when issuing the certificate 
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however, it can be transmitted to the sender, upon request, 
each time he/she signs a docxjment. Therefore, at the end of 
the algorithm depicted on figure 2a, the resulting file is 
signed and contains a link to a server wherein a certificate 
5 may be recovered to check the integrity of the resulting 
file or to verify the embedded signature. 

Figure 2b illustrates an example of the algorithm that 
can be used to check the integrity or to verify the signa- 
ture of a signed file encoded according to the invention. 

10 The first step consists in decoding the filename of the 
file, as described above, to retrieve the address or URIi 
wherein the certificate that is required to check the integ- 
rity or to verify the signature is stored (step 225) . Then, 
using this decoded address or URL, the user can access the 

15 certificate from a server, preferably controlled by a certi- 
fication authority (steps 230 and 235), without opening the 
file. At this stage, the user can access information related 
to the certificate, such as the name of the person to whom 
the certificate has been delivered, the validity period of 

20 the certificate and the signature algorithm. Therefore, the 
user is able to check the certificate to determine whether 
or not the owner of the certificate is the one he/she 
expects to be (steps 240 and 245) . Then, using the public 
key of the certificate, it is possible to authenticate the 

25 file i.e., to check the integrity of the file and/or to 
verify the signature (steps 250 and 255), by using a 
standard authentication algorithm. As suggested by dotted 
lines, the user can authenticate the signed file without 
checking the certificate. Naturally the certificate can 

30 contain information relative to the authentication algorithm 
that could be used, or must be used, depending upon the 
certification authority policy. Still in a preferred embodi- 
ment, the certification authority can provide the user means 
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to download an authentication applet when he/she accesses 
the certificate so as to check the integrity and verify the 
signature of the file. 

Figure 3 depicts an example of the environment wherein 
the invention can be implemented. For sake of illustration 
the main steps of the algorithms described on figures 2a and 
2b are illustrated with referenced arrows. As described 
above, a user (300) who has no certificate and who wants to 
sign a file must access a certification authority server 
(310) through a network (305) e.g-, Internet. Certificates 
generated by the certification authority (320) are locally 
stored in a certificate database (315) of the certification 
authority server (310) . Likewise, when a user (325) having a 
signed file e.g., received as an e-mail attachment, wants to 
check its integrity and to verify the signature, he/she 
accesses through a network (305) the public key of the 
certificate which address or URL is encoded in the filename 
of the signed file to check. 

Figure 4 shows a signed file (400) comprising the 
document (405) and a signature (410) that can be used to 
check the file integrity and to verify the identity of the 
docxxttient's author. The address or URL of the certification 
authority server wherein the certificate corresponding to 
the private key used to sign the file is encoded and stored 
in the filename (415) . 

Figure 5, comprising figures 5a to 5f, illustrates an 
example of the user's interface when using the invention. 
Figures 5a to 5d depict an example of certificate pemel 
while figures 5e and 5f show how a certificate address or 
URL Ccin be linked to a file. 
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The certificate panel illustrated on figures 5a to 5d 
comprises 4 tabs depicted on each of these figures, respec- 
tively, these tabs comprising information relative to: 

- general tab: 

• owner of the certificate, 

certification authority having delivered the 
certificate, and, 

• validity period, 

- detail tab: 

• version identifying the certificate format, 

• serial number (uniq[ue within the certification 
authority) , 

• signature algorithm (identifying the issuer's hash 
algorithm and digital signature algorithm used to sign the 
certificate) , 

issuer name (the name of the certification 
authority) , 

• the beginning of the validity period, 

• the end of the validity period, 

" subject name (the name of the user to whom the 
certificate is issued) , 

• subject's public key field (including Algorithm 
name and the Public Key of the sxibject) , 

• extensions, and, 

• signature of the certification authority, 

certification path (address or URL of the certificate 
on the certification authority server) , and, 

- download SW (comprises links software applications or 
applets that are adapted, for exan5>le, to check the valid- 
ity of a file or to verify a signature) . 
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Most of these fields are completed by the certification 
authority after having received a request for a certificate 
and an identifier or subject name. The private and public 
keys are computed according to standard algorithms. 

5 Figuxes 5e and 5f depict an example of the interface 

that can be used to encode a certificate address or URIi into 
the filename of a file. After having selected a file in the 
file manager, the user can click on the right button of the 
mouse to display a pop-up menu comprising a "Paste path to 
10 file" option. Then, the path previously memorized in the 
clipboard or selected by other means is encoded in the 
filename of the file according to the method described by 
reference to figure 1. 



Naturally, in order to satisfy local and specific 
15 requirements, a person skilled in the art may apply to the 
solution described above many modifications and alterations 
all of which, however, are included within the scope of 
protection of the invention as defined by the following 
claims . 
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Claims : 

1. A method for encoding in the filename of a signed file, 
an address from which the certificate required to authenti- 
cate said signed file can. be accessed, said method compris- 
5 ing the steps of, 

encoding said address from which the certificate 
required to authenticate said signed file can be accessed 
(step 110) ; 

- merging said filename and said encoded address in a new 
10 filename (step 115); and, 

- renaming said signed file with said new filename (step 
120), 

wherein said filename and said encoded addresses are . 
separated by a control character • 

15 2. The method of claim 1 wherein said step of encoding the 
address from which the certificate required to authenticate 
said signed file ccin be accessed comprises the steps of : 

analyzing the address from which the certificate 
required to authenticate said signed file can be accessed 
20 to detect predetermined characters (step 135) ; and, 

- replacing said predetermined characters by associated 
characters (step 140) , 

said predetermined and associated characters being stored 
in a lexicography table (145) . 

25 3. The method of either claim 1 or claim 2 wherein the 
encoded address is merged with said filename, by inserting 
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the encoded address in front of the extension dot of said 
filename. 

4. The method of any one of claims 1 to 3 further compris- 
ing a compression step to reduce the size of the encoded 
5 address . 

5« A method for authenticating a signed file having a 
filename wherein an address from which the certificate 
required to authenticate this signed file can be accessed is 
encoded, said method comprising the steps of, 

10 - extracting said encoded address; 

- decoding said encoded address (step 225); 

- accessing said certificate required to authenticate said 
signed file using said decoded address (steps 230 and 
235) , 

15 - authenticating said signed file using said accessed 

certificate (steps 240 to 255) . 

6. The method of claim 5 further comprising the step of 
checking said certificate before authenticating said signed 
file. 

20 7. The method of either claim 5 or claim 6 wherein said 
step of accessing said ceruifxcace required to authenticate 
said signed file further comprises the step of, 

downloading an authentication function according to 
information contained in said certificate. 

25 8. The method of any one of claims 5 to 7 wherein, said 
step of authenticating ssdLd signed file comprises at: least 
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one of the steps consisting in checking the integrity of 
said signed file and in verifying the signature. 

9. The method of any one of claims 5 to 8 further compris- 
ing the step of extracting a public key from said certifi- 

5 Gate, said public key being used to authenticate said signed 
file. 

10 . The method of any one of claims 1 to 9 wherein said 
certificate is stored in a server of an authentication 
authority. 

10 11. An apparatus comprising means adapted for carrying out 
each step of the method according to any one of the claims 1 
to 10. 

12. A computer-like readable medium comprising instructions, 
for carrying out each step of the method according to auiy' 
15 one of the claims 1 to 10. 



FR920040018 

23 

METHOD AND SYSTEM FOR LINKING 
CERTIFICATES TO SIGNED FIDES 

Abslixract: 

A method and systems for linking the certificate to the 
5 signed file to which it is associated is disclosed. Accord- 
ing to the method and systems of the invention, the address 
or URIi wherein the certificate is stored is encoded in the 
filename of the signed file so as to be transmitted jointly 
with the file. When receiving such a signed file, a first 

10 step consists in extracting and decoding the certificate 
addxess from the filename. Using the certificate address, 
the certificate can be accessed and checked before opening 
and authenticating the signed file. In a preferred embodi- 
ment, the signature of a signed file is based on the file 

15 content and on a private key while the corresponding 
certificate comprises at least the corresponding public key. 
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31/03^004 



To: ifriclay65@yahoo.com 
cc: cc: 

Subject Subject: Le due de Berry 



John, 

The Tr6s riches heures du due de Berry" is usually referred to 
as 'le roi des manuscn'ts entuminte* or "the king of the 
iirumlnated manuscripts", but it is also a pinnacle in the entire 
history of painting. 

Commissioned by Jean, due de Berry in 1413, it was painted by 
the Limbourg brothers who left it unfinished at their (and the 
dub's) death un 1416. TTie due Charles I de Savoie 
commissioned Jeari Colombe to complete the painting of ^e 
manuscript between 1485-1489. 

See attached a signed copy of the draft of my doctoral thesis 
from my research on this subject 

J 1 ^ les 

I Berry (Ht tip. .( (www. certauth. com ( 
» certi f icates ( Lewis Carroll . cer > . doc | 
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Best regards. 



Lewis Carroll 

WONDERI-AN Project 

IBM Corp. t^CarTO»@IBIVlCOM 
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iclkflkmej5daoif3441klki1k08+kadlkdf!ioe9934-ialkfdlasd 
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END SIGNATURE 



LES TRES RICHES HEURES DU DUG DE BERRY 
Lewis Carroll, wondbuand vnaeeu ibm cnp. 

VTHAT IS THE TRES RICHES HEURES? 

The Tres Riches Heures is the classic example of a medieval book of hours. This was a 
collection of the text for eadi liturgical hour of the day - hence the name - which often 
included other, supplementaiy« texts. Calendars, prayers^ psalms and masses for certain 
holy days were commonly included. 

The pictures in this directory are from the calendar section of the Tres Riches Heures. 
This was painted some time between 1412 and 141 6 and is arguably the most beautilul 
part of the manuscript; it is certainly the best known, being one of the great art treasures 
of Fhmoe. In tenns of historical and cultural importance; it is certainly equal to more 
&mous works such as the Mona Lisa, marking the pirmacle of the art of manuscript 
illumination. 

WHO PAINTED THE TRES RICHES HEURES? 

The Tres Riches Heures was painted by the Umbourg brothers, Paul, Hermann and Jean. 
They came from Nimwegen in what is now Flanders but were generally referred to as 
Germans.Veiy linle is known about them; they are believed to have been bom in the late 
1 370s or 1 380s and were bom into an artistic iamily, their father being a wood sculptor 
and their uncle being an artist working variously for the French Queen and for the Due de 
Bourgogne. 

They seem to have followed in their uacU^s footsteps and by 1402 had entered into the 
service of die Due de Bourgogne as artists. By 1408 they had entered the service of Jean, 
Due de Berry, one of the most notable (and richest!) art lovers in France. They are known 
to have executed several other pieces of work apart fitmi Ihe Tres Riches Heures but most 
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